1. Field of the Invention
The present invention relates to data networks, and more particularly, to a fast, lightweight, reliable, packet-based transport protocol that operates independent of the type of underlying protocol used by the network.
2. Background of the Invention
The most popular transport protocol in use today is the Transmission Control Protocol (TCP) defined in the framework of the Internet Protocol (IP) Suite. The TCP protocol provides upper protocol layers and/or applications with a reliable, connection-oriented, strictly in-order delivery, byte-stream transport service. TCP achieves reliability by means of an acknowledge-and-retransmission mechanism. Generally speaking, a receiving TCP entity acknowledges every packet it receives from the transmitting TCP entity. When one of such acknowledgments is not received within a certain period of time (called the Retransmission Timeout), the transmitting TCP entity assumes that the corresponding packet has been lost in the network and retransmits it. This retransmission mechanism has been improved over the years in order to make it more efficient. For example, an algorithm called Fast Retransmit has been added to TCP to trigger a retransmission of a missing packet well before a the retransmission timeout occurs. Also, the retransmission timeout has been made adaptive to the network size and load by adding an estimator of the round-trip-time, i.e., the time it takes for a TCP packet to reach its destination plus the time necessary for its acknowledgment to come back.
The TCP protocol also provides a flow control function, which is defined as the ability of the receiving node to control the rate at which packets are transmitted to it to prevent the overflow of its input buffer. To this end, TCP employs a flow control mechanism called sliding window. A receiving TCP entity continuously informs the transmitting TCP entity about the amount of free input buffer (the so called offered window). When this amount drops to zero, the transmitting TCP entity refrains from transmitting any further data to the receiving entity until new space becomes available in the input buffer.
Another important capability built into TCP is the congestion control function. It has already been noted that when a transmitting TCP entity does not receive an acknowledgment, it assumes the packet was dropped by the network. There are many reasons for which the network can drop a packet, e.g., data corruption, faulty links and/or network, buffer congestion, etc. Of all those reasons, congestion is the by far the most common, especially in large networks such as the Internet. Therefore, when an acknowledge goes missing, TCP not only assumes that a packet was dropped, it also assumes that the reason for this drop is network congestion. A number of algorithms such as Slow Start and Fast Recovery have been embedded into TCP in order to deal with congestion. The purpose of such algorithms is to throttle down the transmission rate in different ways depending on the severity of the congestion detected in the network.
One problem with TCP is that the three functions mentioned above, i.e., reliable delivery, flow control, and congestion control as well as other functionality make it an extremely complex protocol from the implementation standpoint. As a result, most network nodes typically implement TCP as a software module embedded in the operating system. Clearly this solution is not particularly fast and also consumes CPU cycles that could be used to run user applications. There are also a few TCP implementations that rely on micro-controller chips and special software (micro-code) to offload the system CPU from the task of running TCP. This solution is faster and more efficient than the previous one, but is still inadequate for high speed (i.e., multi gigabit per second) networks.
A fast, lightweight, reliable, packet-based protocol that operates independent of the type underlying protocol layer is therefore needed.